public inbox for ecos-maintainers@sourceware.org
 help / color / mirror / Atom feed
* Orphan packages
@ 2009-01-31 21:04 John Dallaway
  2009-01-31 22:26 ` Jonathan Larmour
  0 siblings, 1 reply; 3+ messages in thread
From: John Dallaway @ 2009-01-31 21:04 UTC (permalink / raw)
  To: ecos-maintainers

eCos maintainers

There are currently 4 eCos packages in the repository with no
corresponding package record in ecos.db:

  CYGPKG_HAL_OPENRISC at hal/openrisc/arch
  CYGPKG_HAL_OPENRISC_ORP at hal/openrisc/orp
  CYGPKG_DEVS_FLASH_OPENRISC_ORP at devs/flash/openrisc/orp
  CYGPKG_DEVS_FLASH_SST_39VF400 at devs/flash/sst/39vf400

Such orphan packages will not be present in the forthcoming release, but
does anyone have a good reason to keep any of them in the repository at
all? If these packages might be useful to someone then they should each
have a corresponding package record in ecos.db which includes details of
their status. Otherwise, even regular eCos users may not be aware of
their existence. If no-one cares about these packages, I suggest we
remove them from the repository for reasons of consistency.

John Dallaway

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Orphan packages
  2009-01-31 21:04 Orphan packages John Dallaway
@ 2009-01-31 22:26 ` Jonathan Larmour
  2009-02-01  9:46   ` John Dallaway
  0 siblings, 1 reply; 3+ messages in thread
From: Jonathan Larmour @ 2009-01-31 22:26 UTC (permalink / raw)
  To: John Dallaway; +Cc: ecos-maintainers

John Dallaway wrote:
> eCos maintainers
> 
> There are currently 4 eCos packages in the repository with no
> corresponding package record in ecos.db:
> 
>   CYGPKG_HAL_OPENRISC at hal/openrisc/arch
>   CYGPKG_HAL_OPENRISC_ORP at hal/openrisc/orp
>   CYGPKG_DEVS_FLASH_OPENRISC_ORP at devs/flash/openrisc/orp
>   CYGPKG_DEVS_FLASH_SST_39VF400 at devs/flash/sst/39vf400
> 
> Such orphan packages will not be present in the forthcoming release, but
> does anyone have a good reason to keep any of them in the repository at
> all? If these packages might be useful to someone then they should each
> have a corresponding package record in ecos.db which includes details of
> their status. Otherwise, even regular eCos users may not be aware of
> their existence. If no-one cares about these packages, I suggest we
> remove them from the repository for reasons of consistency.

I know there are outstanding patches for the openrisc stuff stuck way way 
back in the patch backlog. The packages should not be deleted. I know from 
the lists that some people have been using the openrisc port, which means 
they must be using them with the patches applied. I definitely don't 
expect we will reach the point of reviewing (with possible subsequent 
modifications) the patches before 3.0, so I think the status quo will have 
to do.

The latter package appears obsoleted by the SST_39VFXXX package so can 
probably go, although I have slight hesitation to do this because 
third-party ports could be using it. Doesn't seem worth keeping though.

Jifl
-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["The best things in life aren't things."]------      Opinions==mine

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Orphan packages
  2009-01-31 22:26 ` Jonathan Larmour
@ 2009-02-01  9:46   ` John Dallaway
  0 siblings, 0 replies; 3+ messages in thread
From: John Dallaway @ 2009-02-01  9:46 UTC (permalink / raw)
  To: Jonathan Larmour; +Cc: ecos-maintainers

Hi Jifl

Jonathan Larmour wrote:

>> There are currently 4 eCos packages in the repository with no
>> corresponding package record in ecos.db:
>>
>>   CYGPKG_HAL_OPENRISC at hal/openrisc/arch
>>   CYGPKG_HAL_OPENRISC_ORP at hal/openrisc/orp
>>   CYGPKG_DEVS_FLASH_OPENRISC_ORP at devs/flash/openrisc/orp
>>   CYGPKG_DEVS_FLASH_SST_39VF400 at devs/flash/sst/39vf400
>>
>> Such orphan packages will not be present in the forthcoming release, but
>> does anyone have a good reason to keep any of them in the repository at
>> all? If these packages might be useful to someone then they should each
>> have a corresponding package record in ecos.db which includes details of
>> their status. Otherwise, even regular eCos users may not be aware of
>> their existence. If no-one cares about these packages, I suggest we
>> remove them from the repository for reasons of consistency.
> 
> I know there are outstanding patches for the openrisc stuff stuck way
> way back in the patch backlog. The packages should not be deleted.

OK.

> I
> know from the lists that some people have been using the openrisc port,
> which means they must be using them with the patches applied. I
> definitely don't expect we will reach the point of reviewing (with
> possible subsequent modifications) the patches before 3.0, so I think
> the status quo will have to do.

OK, but perhaps we should add corresponding package records (with
suitable caveats in the description field) after branching for eCos 3.0.
There are other packages in the repository which have a broadly similar
status but have a package record so people are much more likely to be
aware of their presence.

> The latter package appears obsoleted by the SST_39VFXXX package so can
> probably go, although I have slight hesitation to do this because
> third-party ports could be using it. Doesn't seem worth keeping though.

ACK. Any users of the package will be aware that it's not a current
package due to the lack of a package record in ecos.db. Of course, the
code will still be in the CVS attic.

John Dallaway

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2009-02-01  9:46 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-01-31 21:04 Orphan packages John Dallaway
2009-01-31 22:26 ` Jonathan Larmour
2009-02-01  9:46   ` John Dallaway

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).