incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Juergen Schmidt <jogischm...@googlemail.com>
Subject Re: [RELEASE]: proposed directory structure on dist
Date Tue, 01 May 2012 20:58:02 GMT
On Tuesday, 1. May 2012 at 22:10, Kay Schenk wrote:
> On Tue, May 1, 2012 at 11:23 AM, Jürgen Schmidt
> <jogischmidt@googlemail.com>wrote:
>  
> > On 4/30/12 11:16 PM, Kay Schenk wrote:
> >  
> > >  
> > >  
> > > On 04/30/2012 12:47 PM, Roberto Galoppini wrote:
> > >  
> > > > On Mon, Apr 30, 2012 at 8:47 PM, Marcus (OOo)<marcus.mail@wtnet.de>
> > > > wrote:
> > > >  
> > > > > Am 04/30/2012 07:00 PM, schrieb Rob Weir:
> > > > >  
> > > > > On Mon, Apr 30, 2012 at 12:44 PM, Kay Schenk<kay.schenk@gmail.com>
> > > > > > �wrote:
> > > > > >  
> > > > > > <snip>
> > > > > >  
> > > > > > Right now I have the DL friendly script setup to only use SF...which
> > > > > > > is
> > > > > > > setup in the "old" way. I don't think we'll be usign Apache
for
> > > > > > > pre-build
> > > > > > > client downloads.
> > > > > > >  
> > > > > > > So, I have a question -- who will be setting up the SF
packs and will
> > > > > > > they
> > > > > > > just stick with the current structure on that system for
DLs --
> > > > > > >  
> > > > > > > i.e.
> > > > > > >  
> > > > > > > <root>/files/stable/<version>/
> > > > > > > <pack name>
> > > > > > >  
> > > > > > > and
> > > > > > >  
> > > > > > > <root>/files/localized/<**language>/<version>/<pack
name>
> > > > > > >  
> > > > > > > I'm hoping the answer is "YES".
> > > > > > Whatever we do, let's try to get a directory schem that works
now and
> > > > > > for AOO 3.4.1 and AOO 3.5 and for AOO 4.0, etc.. �This is
not
> > > > > > something where it will be easier to clean up later.
> > > > > >  
> > > > >  
> > > > >  
> > > > >  
> > > > > Honestly spoken, I don't know if this will work.
> > > > >  
> > > > > Of course it could be easy and fast to think about a directory structure
> > > > > that will work also for a AOO 5.0 release.
> > > > >  
> > > > > However, I doubt that we will have the time to make the DL logic
work
> > > > > this
> > > > > way, too.
> > > > >  
> > > > > As I've no idea how close we are from the first public download of
AOO
> > > > > 3.4 I
> > > > > wouldn't do bigger changes now.
> > > > >  
> > > > >  
> > > > > Thinking ahead, what do we do when we have a new release, like a
> > > > > > 3.4.1? �And what can we do now to make that future less painful?
> > > > >  
> > > > >  
> > > > >  
> > > > > The DL logic for 3.4.1 can be the same as for 3.4.0. There shouldn't
be
> > > > > big
> > > > > changes. For further releases see above.
> > > > >  
> > > > > Juergen is already OK to setup the structure like it was in the old
> > > > > project,
> > > > > so that the need changes to the DL logic is minimal.
> > > > >  
> > > >  
> > > >  
> > > > It seems the easiest way to go to me too.
> > > >  
> > > > Roberto
> > >  
> > > OK, I need some clarification here -- again.
> > >  
> > > I am to understand by the above statements by Marcus and Roberto that
> > > the directory structure for 3.4 will be the same as it is for 3.3, but....
> > >  
> > >  
> > > we will have a *different* structure on www.apache.org/dist? Also, OK,
> > > we just need some awareness.
> > >  
> > > So -- can someone tell me what's what here.
> >  
> > I am currently also confused. I would still prefer my proposed structure
> > in the beginning of this thread if it is possible.
> >  
>  
>  
> Your very first suggestion would entail *really* major changes right now,
> so this is the LEAST of my favorite!
>  
>  
> > That would allow us to easy add further platforms and keep the bits a
> > little bit separated. Think about 100 languages and 5 files (including the
> > checksum files) for each downloadable file.
> >  
> > And it will work for future releases as well.
> >  
> > I have agreed to use the same structure as for 3.3 but I also have said
> > that I skip the version in the localized folder because we already have it
> > in the path. No direct feedback on this and I took it as common consensus.
> >  
>  
>  
> OK, I don't understand this last bit.
Well I gave a very clear example how I planned to organize the bits on dist based on a structure
that came from Marcus . And this was slightly different than the former structure but closer
to my proposal. And no clear veto or response so I took it as accepted.
>  
> Please again take a look at to the current setup on SourceForge:
>  
> <DL url>/files/localized/<language-code>/3.4.0/<packages>
>  
> It would simplify our rollout if we could just stick with the current
> structure on SourceForge. We will be using that as our primary DL mirror
> for clients.
>  
>  

We will do that but in general the dist folder should be our reference for all mirrors.  
>  
> Marcus's alternate suggestion of :
>  
> <root-path>/files/3.4.0/...
> <root-path>/files/3.4.1/...
> <root-path>/files/3.5.0/...
>  
> seems like a good option to me as well, and you responded to this. But, the
> least amount of change -- i.e. keeping the structure we have -- is really
> the best at this point in terms of getting something done in a reasonable
> time. Maybe we could discuss alternatives for *after* 3.4 in the future? We
> are planning on a retool of the DL script after this, and incorporating
> easier ways to deal with changes like this are high on the priority list.
>  
> Right now, we are planning on using SF for the majority of downloads --
> typical clients -- and that structure -- good or bad -- is already in
> place, and the test DL script is working based on this.
>  
>  

taken and we will keep the old structure  
>  
> We will probably only use the Apache "dist" system for source.
> So, in terms of how you setup things there I don't really care, but, of
> course, we need information about that.
>  
well we should care about it, the dist folder is the place where releases are provided and
where the release manager have to upload the bits.
And I would have preferred to have a clean structure from the beginning.  

For me the future and future releases are more important than older versions. But it is of
course good to have the older versions available.
>  
>  
> As silly as this probably seems to you, could we PLEASE just stick with the
> current structure for now?
>  
Yes, we will go with the old structure for now

Juergen  
>  
>  
> > But now I am confused. We should clarify the structure before I will start
> > the upload tomorrow.
> >  
> > I haven't looked in the details behind the download scripts and don't know
> > how much work it is to adapt them to a new directory structure. That means
> > I will use the structure that will work for now.
> >  
> > Juergen
> >  
> >  
> >  
> >  
> > > I CAN change the friendly scripts to go with the NEW (Apache) structure.
> > > In fact I'm going to work on THAT approach today (along with Rob's
> > > changes) and hopefully we'll be set for either instance.
> > >  
> > >  
> > >  
> > > > To setup a new structure that makes maybe more sense can be done later
> > > > > for a
> > > > > release after 3.4.x.
> > > > >  
> > > >  
> > > >  
> > > >  
> > > > my 2 ct
> > > > >  
> > > > > Marcus
> > > > ====
> > > > This e- mail message is intended only for the named recipient(s) above.
> > > > It may contain confidential and privileged information. If you are not
the
> > > > intended recipient you are hereby notified that any dissemination,
> > > > distribution or copying of this e-mail and any attachment(s) is strictly
> > > > prohibited. If you have received this e-mail in error, please immediately
> > > > notify the sender by replying to this e-mail and delete the message and
any
> > > > attachment(s) from your system. Thank you.
> > > >  
> > >  
> > >  
> >  
> >  
>  
>  
>  
> --  
> ----------------------------------------------------------------------------------------
> MzK
>  
> "Well, life has a funny way of sneaking up on you
> And life has a funny way of helping you out
> Helping you out."
> -- "Ironic", Alanis Morissette
>  
>  



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message